Magnetic tape provides a means for physically storing data which may be archived or which may be stored in storage shelves of automated data storage libraries and accessed when required. Data stored in this manner has an aspect of permanence which allows copies of the data stored in memory or disk at a host system to be erased, knowing that a copy exists on magnetic tape. The available storage space at the host system is relatively expensive, and there is a desire to release the storage space as soon as possible. Hence, data is typically transferred through an intermediate staging buffer, such as a hard disk, to the tape drive, and there is also a desire to release and overwrite the staging buffer as soon as possible.
Thus, it is often desirable to “synchronize” the data.
“Synchronized data” is defined as data or other information which is subject to a “synchronizing event” or similar command requiring the tape drive to not return “Command Complete” to a write type of command, or an indication that the command has been or will be successfully executed, until it has actually committed the data to media, specifically, the magnetic tape. As the result, if power is lost, the data can be recovered from the tape, whereas it may not be recoverable from a volatile DRAM storage of the tape drive buffer.
One example of a synchronizing event is a Write Filemark command with the Immediate bit set to “0”. This means that the drive is not to respond immediately, but instead is to respond when the command has completed, meaning that any data sent as part of the command is written out to tape. A specialized case of a Write Filemark command is where the number of Filemarks field is also set to “0”, meaning that the Write Filemark command has no data of its own, and thus the sole purpose of the command is to assure that all data which precedes the command must be written to tape before a command complete is sent. Hence, this command is often referred to as a “Synchronize” command, as is known to those of skill in the art.
Another example of a synchronizing event is a host selectable write mode known to those of skill in the art as “non-buffered writes”, where an implicit synchronize must be performed after each record is written from the host. “Command Complete” is not returned for any write command until the data is successfully written on media.
Herein, writing any data record, group of records, or other mark, is defined as a “transaction”, and writing such data record, etc., as the result of a synchronizing event is defined as a “synchronized transaction”.
A difficulty with respect to magnetic tape is that the data is recorded sequentially without long gaps between data sets, whereas synchronized transactions are stored in separate bursts for each synchronizing event, with a noticeable time period before writing the next transaction. This requires that the tape drive “backhitch” after writing the synchronized transaction in order to write the next transaction closely following the preceding transaction. Tape is written or read while it is moved longitudinally at a constant speed. Hence, a backhitch requires that the tape be stopped, reversed to beyond the end of the previous transaction, stopped again, and accelerated up to speed in the original direction by the time that the end of the previous transaction is reached. As is understood by those of skill in the art, the backhitch process consumes a considerable amount of time, and, if a large number of small synchronized transactions are to be stored, the throughput of the tape drive is reduced dramatically. As an example, backhitch times can vary from about half a second to over three seconds.
The incorporated '101 Application solves the problem by writing synchronized data transactions to magnetic tape without stopping the tape, perhaps leaving gaps between the transactions, accumulates the synchronized transactions in a buffer, and subsequently rewrites the accumulated transactions from the buffer to the magnetic tape in a sequence. This is now called “Recursive Accumulating Backhitchless Flush”, or “RABF”, in the art. With large sized transactions relative to buffer size, it is possible that the buffer will fill with the accumulated transactions relatively quickly, forcing the recursive writing of the transactions and holding off the receipt of additional data during the recursive writing, such that non-RABF performance will approach that of RABF recording.